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REMARKS 

Claims 1-39 are pending in this application. Claims 1,9, 19 and 31 are independent. 
Applicant proposes amending claims 1, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 26, 27, 28, 
31, 32, 33, 34, 35, 36, 37, 38, and 39. 

Claims 1-39 stand rejected under 35 U.S.C § 101 as be directed to non-statutory 
subject matter. 

Claims 31-39 stand rejected under 35 U.S.C. § 102 (b). Claims 1 - 15, 25 - 30, and 
38 stand rejected under 35 U.S.C. § 103 (a). 

Reconsideration in view of the above-listed amendments and the following remarks is 
respectfully requested. 

Interview Summary 

The undersigned wishes to thank Examiner Sciacca for granting the telephonic 
interview of August 4, 2008. 

During the interview, Applicants proposed amendments and arguments substantially 
consistent with those presented herein. Examiner Sciacca agreed to give further 
consideration to the arguments upon submission of a written response. 

Rejection Under 3 5 U.S.C. § 101 

Claims 1-39 stand rejected under 35 U.S.C § 101 as be directed to non-statutory 
subject matter. While not agreeing with the basis for the rejections, Applicant proposes 
amending the claims in order to advance prosecution. 

With respect to claims 1 , Applicant proposes to amend the claim to recite elements of 
a computing system in the recited method. With respect to claim 9, Applicant proposes to 
amend the claim to recite a computer-readable "storage" medium. With respect to claim 19, 
Applicant proposes to amend the claim to recite steps performed at a computer device. 
Claim 3 1 has been amended to recite a method. 

Reconsideration and withdrawal of the rejections under 35 U.S.C § 101 is respectfully 
requested. 
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Rejections under 35 U.S.C. § 102/103 

Claims 31-39 stand rejected under 35 U.S.C. § 102(b) as allegedly being anticipated 
by U.S. Patent 5,261,085 (the "085 patent"). 

Claims 1 - 4, 6 - 14 and 26 - 30 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over the 085 patent in view of Paxos Made Simple ("Paxos") from 
Applicant's IDS dated December 30, 2003. 

Claims 5, 15 and 25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over the '085 Patent in view of Paxos in further view of U.S. patent publication 
2003/0227392 (the "392 Application"). 

Claim 38 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over the 
'085 Patent in view of U.S. patent publication 2002/01 12198 (the "198 Application"). 

Reconsideration is respectfully requested. 

Applicant notes in the patent application specification that: 

[I]n the event of conflicts, the Fast Paxos algorithm can, by 
performing the first phase of the standard Paxos algorithm, 
introduce more message delays than would have otherwise 
been present if the system 10 had been using the standard 
Paxos algorithm all along. Because conflicts can arise 
frequently in an environment in which more than once 
device may seek to act as a client , a reduced message delay 
consensus algorithm such as Fast Paxos may not provide 
the expected efficiencies unless it can continue operating 
properly in the face of conflicting client proposals, flj 
[0108]). 

Applicant has therefore disclosed: 

[A] system can implement a reduced message delay consensus 
algorithm that is conflict tolerant. Turning to FIG. 8a, an 
exemplary environment is shown comprising one client device 
20, and additional devices 11-15 that are both the constituent 
devices of the distributed computing system 10, and can act as 
clients of the system 10. Furthermore, as shown, each of the 
devices 11-15 and the client 20 can be assigned a client 
identifier. In one embodiment contemplated by the present 



Page 14 of 20 



DOCKET NO.: MSFT-5033/305892.01 
Application No.: 10/750,601 
Office Action Dated: May 13, 2008 



PATENT 



invention, the constituent devices of the system 1 0 essentially 
vote for a combination of a proposed function, and the 
particular device that proposed the function. Thus, while a 
device might vote for a proposed function from one device, 
it might not vote for the same proposed function if it was 
proposed by a different device. As will be shown in more 
detail below, a reference to the identifier of the device 
proposing the function can help provide conflict tolerance, flf 
[0110]). 



Claim 1 recites: 

A method for selecting a value in a distributed computing 
system, the method comprising: 

receiving at a computing device from a first client a 
first message comprising a first proposed value and a first 
client identifier corresponding to the first client ; 

voting at the computing device for the first proposed 

value; 

transmitting from the computing device a first 
indication of the voting for the first proposed value to one or 
more devices; and 

transmitting from the computing device a first result of 
the voting for the first proposed value to the first client, 

wherein the voting for the first proposed value, the 
transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result are not 
performed if a second message is received at the computing 
device from a second client , the second message comprising 
a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier 
being more dominant than the first client identifier and the 
second proposed value having been previously voted for . 

In order for a reference to anticipate this claim, or a set of references to render the claim 
obvious, the recited language and its combination in the recited method must be taught by the 
prior art. The undersigned respectfully submits that the cited references do not teach the 
emphasized language and cannot possibly teach or even suggest the recited method. 

The 085 patent discloses system for implementing a state machine. In the 085 patent, 
one process in a network of processes is chosen as the leader, and that leader is responsible 
for broadcasting state machine commands to other processes. (Abstract). Each command is 
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broadcast through a numbered ballot and each process may either accept the command or not 
vote. (Abstract). In order for a command to be issued, the command must be voted for by a 
majority of the processes in the system. (Abstract). 

Thus, the 085 patent discloses a system wherein a single leader is designated 
to broadcast machine commands and the individual processes vote on the commands. In 
contrast to claim 1, the 085 patent does not disclose or suggest "receiving at a computing 
device from a first client a first message comprising a first proposed value and a first 
client identifier corresponding to the first client" and receiving "a second message ... at 
the computing device from a second client the second message comprising a second 
proposed value and a second client identifier corresponding to a second client." Rather, 
in the system disclosed in the 085 patent, it appears that messages are received from a single 
"client," namely the "leader." In other words, the 085 patent does not disclose or suggest 
receiving a first message "from a first client" and receiving a second message "from a second 
client." Indeed, the concept of selecting a leader teaches away from a system wherein 
messages may be received from a plurality of client devices; if there was a leader, messages 
would not be received from a plurality of client devices. 

Moreover, because the 085 patent appears to teach a single leader, and not receiving 
messages from a first client and a second client, the 085 patent cannot possibly teach "not" 
performing "the voting for the first proposed value, the transmitting the first indication of the 
voting for the first proposed value, and the transmitting the first result" if "a second message 
is received . . . the second message comprising a second proposed value and a second 
client identifier corresponding to a second client, the second client identifier being more 
dominant than the first client identifier and the second proposed value having been 
previously voted for." 

The Office also relies upon the Paxos algorithm for the rejection. Applicant 
acknowledges the existence of Paxos, and, in fact, discusses the Paxos algorithm and another 
algorithm known as the Fast Paxos algorithm in the present application. (See e.g., Tfff [0008] - 
[0013]). Applicant has noted that both algorithms have limitations. In particular, the Paxos 
algorithm introduces delays: 
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However, the Paxos algorithm adds message delays between 
when a client sends a request for the distributed system to 
execute a command, and when the client receives the results 
from the execution that command. Specifically, even if the 
client transmits a request to a leader, and even if the leader has 
already learned of previously voted on proposals, and thus has 
completed the first phase of the Paxos algorithm, there can still 
be two or more message delays between the transmission of the 
request from the client, and the transmission of the results to 
the client. Furthermore, the Paxos algorithm can require the 
presence of a leader device that receives client requests and 
determines the appropriate functions to submit for a vote to the 
devices of the distributed computing system. Should such a 
leader device fail, a new leader may not take its place 
immediately, leaving the distributed computing system idle and 
the client waiting for a response to its requests. (Application, If 
[0011]). 

The Fast Paxos algorithm cannot tolerate a conflict among two or more clients. 

[T]he Fast Paxos algorithm cannot tolerate a conflict among 
two or more clients. Specifically, if two or more clients propose 
different functions at approximately the same time, the devices 
may be unable to choose between the different functions. In 
such a case, the system must stop using the Fast Paxos 
algorithm and return to the regular Paxos algorithm, with the 
leader beginning with the first phase, in an effort to resolve the 
discrepancy among the devices in the system. In such a case, 
the two or more clients that submitted the conflicting proposals 
may experience an even greater delay in receiving their 
responses than if the system had never attempted to operate 
using the Fast Paxos algorithm. (Application, If [0013]). 

Applicant has developed a conflict tolerant reduced message delay consensus 
algorithm. In particular, Applicant discloses 

[A] system can implement a reduced message delay consensus 
algorithm that is conflict tolerant. Turning to FIG. 8a, an 
exemplary environment is shown comprising one client device 
20, and additional devices 11-15 that are both the constituent 
devices of the distributed computing system 10, and can act as 
clients of the system 10. Furthermore, as shown, each of the 
devices 11-15 and the client 20 can be assigned a client 
identifier. In one embodiment contemplated by the present 
invention, the constituent devices of the system 10 essentially 
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vote for a combination of a proposed function, and the 
particular device that proposed the function. Thus, while a 
device might vote for a proposed function from one device, 
it might not vote for the same proposed function if it was 
proposed by a different device. As will be shown in more 
detail below, a reference to the identifier of the device 
proposing the function can help provide conflict tolerance . 
(Application, H [01 10]). 

In contrast to claim 1, Paxos does not disclose or suggest "receiving at a computing 
device from a first client a first message comprising a first proposed value and a first 
client identifier corresponding to the first client " and receiving "a second message ... at 
the computing device from a second client , the second message comprising a second 
proposed value and a second client identifier corresponding to a second client ." Rather, 
in the system disclosed by Paxos, proposals are received that are identified by a proposal 
number. The proposal numbers of Paxos do not comprise "a first proposed valued and a first 
client identifier corresponding to the first client" and "a second proposed value and a 
second client identifier corresponding to a second client." 

Furthermore, the Paxos algorithm does not disclose "not" performing "the voting for 
the first proposed value, the transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result" if "a second message is received . . . the 
second message comprising a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier being more dominant than 
the first client identifier and the second proposed value having been previously voted 
for." Rather, the Paxos algorithm relies on proposal numbers to determine what proposal to 
execute. Paxos does not determine or consider "the second client identifier being more 
dominant than the first client identifier." Indeed, the concept is entirely absent. 

The Office notes that Paxos discloses selecting a value in a network where there are 
multiple acceptors. (Office Action, p. 9). In particular, Paxos discloses that a value is chosen 
when a large enough number of acceptors accept the value. 

A proposer sends a proposed value to a set of acceptors. An 
acceptor may accept the proposed value. The value is chosen 
when a large enough set of acceptors have accepted it. 
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But selecting a value because enough acceptors have accepted the value is not the same or 
even similar to "not" performing various activities "if "a second message is received . . . the 
second message comprising a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier bein2 more dominant than 
the first client identifier ." Rather, in Paxos, the selected value is based on whether a 
plurality of other acceptors have also accepted. The selection is not determined by whether a 
client identifier from a second client is more dominant than a first. 

The Office further notes that Paxos discloses an acceptor accepting a proposed value 
if it has not already responded to a request having a greater number. (Office Action, p. 9). 

An acceptor can accept a proposal numbered n if it has not 
responded to a prepare request having a number greater than n. 

Thus, Paxos teaches selecting a proposal based upon a proposal number. The referenced 

section of Paxos does not indicate that a proposal is selected based upon a client identifier as 

recited in the claim. There is not indication that a client identifier is even available to be 

considered in the Paxos algorithm. 

Therefore, because neither the 085 patent nor Paxos disclose the emphasized claim 
language, even in combination the references cannot be said to disclose or suggest the recited 
combination of claim 1 . For similar reasons, claims 9, 19 and 3 1 patentably define over the 
references. 

Applicant notes that other claims further define over the references for additional 

reasons. For example, claim 33 recites: 

wherein the dedicated client device is 
identified by a least dominant client 
identifier . 

The Office cites to the 085 patent for the proposition that the above-reference language of 
claim 33 is anticipated by the following except: "the selection requirement is then satisfied 
by having one of the processes send a message containing its identification number to every 
other process every." Applicant respectfully disagrees. As noted above, the 085 patent relies 
upon a "leader." The 085 patent does not disclose receiving a first message "from a first 
client" and receiving a second message "from a second client." Accordingly, the 085 patent 
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does not disclose selecting a proposed value based upon a dominant client identifier. The 
085 patent likewise does not disclose identifying a dedicated client device by a least 
dominant identifier. For this additional reason, the 085 patent does not teach or disclose each 
and every element of claim 33. The Applicant therefore respectfully submits that claim 33 is 
patentable over the 085 patent. 

Reconsideration and withdrawal of the rejections under 35 U.S.C. § 102 and 103 is 
respectfully solicited. 

CONCLUSION 

The undersigned respectfully submits that pending claims are allowable and the 
application is in condition for allowance. A Notice of Allowance is respectfully solicited. 

Examiner Sciacca is invited to call the undersigned in the event a telephone interview 
will advance prosecution of this application. 



Date: August 12, 2008 



Woodcock Washburn LLP 
Cira Centre 

2929 Arch Street, 12th Floor 
Philadelphia, PA 19104-2891 
Telephone: (215) 568-3100 
Facsimile: (215)568-3439 



/John E. McGlynn/ 
John E. McGlynn 
Registration No. 42,863 
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